This application contains computer program listings attached as Appendix A, Appendix B, Appendix C, and Appendix D. These appendices have been submitted on a single compact disc (in duplicate) which contains Appendix A in a file named xe2x80x9c09275276.APPENDIX A.txtxe2x80x9d of size 6KB created on Feb. 5, 2002, Appendix B in a file named xe2x80x9c09275276.APPENDIX B.TXTxe2x80x9d OF SIZE 66 KB created on Feb. 5, 2002, Appendix C in a file named xe2x80x9c09275276.APPENDIX C.txtxe2x80x9d of size 3 KB created on Feb. 5, 2002, and Appendix D in a file named xe2x80x9c09275276.APPENDIX D.txtxe2x80x9d of size 12KB created on Feb. 5, 2002. The material contained in each of these files is hereby incorporated by reference.
The present invention pertains generally to test and measurement instrumentation, and more particularly to a universal I/O interface which allows communication with an instrument over any one of a plurality of I/O interfaces.
Automated control of instrument devices over I/O buses is prevalent in many test and measurement applications. Automated instrument control allows the instrument configuration and test setup and control to be performed via a computer rather than strictly manually. Automated instrument control is useful in many situations, including circumstances where the test controller and instrument are located remote from one another. When developing an instrument control application, a test and measurement engineer must consider many factors in order to obtain successful communication between the application and instrument. These include the choice of data transport mechanism (i.e., I/O bus and associated controller), instrument drivers, I/O software libraries, and the language in which the application is written. To complicate matters, it is not uncommon for test and measurement applications to use a mix of I/O buses (e.g., VXI and GPIB, or RS-232 and GPIB, etc). Once the underlying I/O bus is chosen, the engineer must then select from a set of available vendors that support the chosen bus. Each vendor may, and typically do, support the bus using different Application Programmer Interfaces (API), thereby requiring the user to learn a different API each time a new vendor is selected.
I/O bus architecture options and available vendors continually change as technology progresses. As just described, each I/O bus defines a different API, which adds complexity to the system and costs valuable engineering time to learn. Accordingly, a need exists for a method for migrating from one bus architecture and/or vendor to another without incurring the overhead associated with learning a new API whenever the I/O solution is changed. In particular, a need exists for a mechanism and method to abstract the I/O type and vendor library and to provide only a single user/client API regardless of the selected I/O type and vendor library.
The present invention solves the problems of the prior art by providing a universal I/O interface that allows communication with a number of different instruments independent of the underlying I/O configuration. The universal I/O interface is a set of Component Object Model (COM) interfaces that are independent of the underlying I/O bus and API. In addition, the universal I/O interface allows instrument data to be parsed and instrument commands to be formatted in a programming language independent way. In the preferred embodiment, the universal I/O interface comprises a COM object known in the art as an ActiveX Automation Server that abstracts the APIs for various possible underlying I/O buses and vendor software libraries into a single universal I/O interface. This allows instrument application programmers to design applications that are universally supported on any number of instrument I/O buses.